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Abstract 

We present a technique for automatically extracting 
temporal mutual exclusion invariants from PDDL2.2 
planning instances. We first identify a set of invariant 
candidates by inspecting the domain and then check 
these candidates against properties that assure invari- 
ance. If these properties are violated, we show that it 
is sometimes possible to refine a candidate by adding 
additional propositions and turn it into a real invariant. 

Our technique builds on other approaches to invariant 
synthesis presented in the literature, but departs from 
their limited focus on instantaneous discrete actions by 
addressing temporal and numeric domains. To deal with 
time, we formulate invariance conditions that account 
for both the entire structure of the operators (including 
the conditions, rather than just the effects) and the possi- 
ble interactions between operators. As a result, we con- 
struct a technique that is not only capable of identifying 
invariants for temporal domains, but is also able to find a 
broader set of invariants for non-temporal domains than 
the previous techniques. 

Introduction 

A number of planning domain specification languages de- 
signed and used to describe complex real-world planning 
problems adopt a constraint-based representation centered 
on multi-valued state variables. Examples of large temporal 
systems based on such languages are: EUROPA2 (Frank and 
Jonsson, 2003), ASPEN (Chien et al., 2000), IxTeT (Ghallab 
and Laruelle, 1994), HSTS (Muscettola, 1994) and OMPS 
(Fratini, Pecora, and Cesta, 2008). 

In contrast, the majority of the benchmark domains cur- 
rently used by the planning community were developed 
for the International Planning Competitions (IPCs) and are 
therefore encoded in the PDDL language, which is proposi- 
tional in nature. Tools designed for translating propositional 
representations into variable/value representations would fa- 
cilitate the testing of application-oriented planners on these 
benchmarks. Designing such tools is primarily concerned 
with the generation of multi-valued state variables from 
propositions and operators, which does not depend on the 
target language of the translation. 

This paper presents a technique for generating tempo- 
ral multi-valued state variables from a PDDL2.2 instance 
(Edelkamp and Hoffmann, 2004; Fox and Long, 2003). 
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More specifically, we describe a technique for identifying 
temporal mutual exclusion invariants , which state that cer- 
tain atoms can never be true at the same time, as a prelimi- 
nary step to synthesizing state variables. In fact, each iden- 
tified group of mutually exclusive atoms constitutes the do- 
main of a single state variable. 

Our technique builds on the invariant synthesis pre- 
sented in Helmert (2009) which is used to translate a sub- 
set of PDDL2.2 into FDR (Finite Domain Representation), 
a multi-valued planning task formalism used within the 
planner Fast Downward (Helmert, 2006). Helmert ’s invari- 
ant synthesis is limited to non-temporal and non-numeric 
PDDL2.2 domains (the so called, PDDL “Level 1”). In con- 
trast, our technique addresses temporal and numeric do- 
mains (PDDL - “Level 3”). Developing invariants for such 
tasks is more complex than handling tasks with instanta- 
neous discrete actions, because interference between con- 
current operators complicates the identification of state vari- 
ables. For this reason, a simple generalization of Helmert ’s 
approach does not work in temporal settings. In extending 
the theory to capture the temporal case, we have had to for- 
mulate invariance conditions that take into account the entire 
structure of the operators (including the conditions, as op- 
posed to the effects only) as well as the possible interactions 
between them. As a result, we have constructed a signifi- 
cantly more comprehensive technique that is able to find not 
only invariants for temporal domains, but also a broader set 
of invariants for non-temporal domains. 

Other approaches to invariant synthesis are available in 
the literature (Gerevini and Schubert, 2000; Rintanen, 2000; 
Fox and Long, 1998). Although similarities with our ap- 
proach can be found, they are more limited in scope be- 
cause they deal only with STRIPS domains. These tech- 
niques have usually been used in combination with SAT- 
based planners (Kautz and Selman, 1999) or Graphplan- 
based planners (Blum and Furst, 1997) for improving their 
performance. 

This paper is organized as follows. In the next section, we 
identify an initial set of invariant candidates by inspecting 
the domain. We then explain how to check the candidates 
against a set of properties that assure invariance in order to 
verify that our initial candidates are actual invariants. If a 
candidate turns out not to be an invariant at first, we show 
that in some cases it is possible to refine the candidate so as 



to make it a real invariant. An experimental evaluation of our 
approach and a presentation of conclusions and future work 
close the paper. 

Invariant Candidates 

An invariant is a property of world states such that when 
it is satisfied by a state s, it is satisfied by all states that 
are reachable from s. Usually, we are interested in invari- 
ants that are satisfied in the initial state. If an invariant holds 
in the initial state, it holds in all the reachable states. Here, 
we focus on mutual exclusion invariants, which state that 
certain atoms can never be true at the same time. For ex- 
ample, if we take the Logistics domain, a mutual exclusion 
invariant for this domain states that two atoms indicating the 
position of a truck t r k 0 , such as at ( t r k 0 , locO) and 
at ( t r k 0 , loci), can never be true at the same time. In- 
tuitively, this means that the truck cannot be at two different 
positions simultaneously. 

In order to find invariants, we use a guess, check and re- 
pair approach sorting through hypothetical invariants, which 
we call invariant candidates. We generate invariant candi- 
dates as described below and then check them against a set 
of conditions that ensure invariance. If a hypothetical invari- 
ant is not found to be valid, we apply a set of refinements to 
try to make it a real invariant before rejecting it. 

Formally, let I = iV,V) be a PDDL instance, where 
V is a planning domain and V a planning problem, an in- 
variant candidate is a tuple C = (<f>,F,V), where <f> is 
a non-empty subset of the atoms in the domain V , and F 
and V are two disjoint sets of variables. The atoms in <f> 
are called the candidate’s components , while the two sets 
F and V are respectively called fixed and counted variables. 
They are both subsets of Var[T>], which collects the variables 
in <f>. For example, if we take the Logistics domain and the 
predicate at (truck, loc) , the following is a candidate: 
Cat = ({at (truck, loc) }, {truck}, {loc}), where 
at (truck, loc) is the only component of this candidate, 
truck is the fixed variable and loc the counted variable. 

An instance 7 of the candidate C is a function that maps 
the fixed variables in F to objects of the problem V. Assum- 
ing we have a problem with two trucks t r k 1 and t r k2 , we 
have two possible instances of C a t - Itrki : truck — » t rkl 
and 7t r /c2 • truck — > trk2. 

The weight of an instance 7 in a state 5 is the number of 
ground instantiations of the variables in V that make some 

G & true under 7 in s. 1 Thus, considering the Logistics 
domain and the instance 7 tr ku if we have a state s where 
the atom at ( t rk 1 , 1 oc 1 ) holds, then the weight of C a t is 
one. Intuitively, the weight of 7 in a state s is the number of 
the candidate’s components that are true in 5 when the fixed 
variables have been instantiated according to 7. 

Given a cardinality set S = {x \ x £ N}, the semantics of 
a candidate C is: for all the possible instances 7 of C, if the 
weight of 7 is within S in a state s , then it is within S in any 
successor state s' of s. Thus, if we prove that the candidate 
C holds (i.e. C is an invariant) and is satisfied in the initial 

x The weight of 7 is equal to the cardinality of the set of all 
ground atoms that unify with some f G $ under 7 in s. 


state, we have that at most k = max(S) atoms in <f> are true 
in any reachable state. Since we focus on finding mutually 
exclusive sets of propositions, we are interested in cases in 
which at most one atom in <f> is true in any reachable state. 
Considering the Logistics domain again, the candidate C a t 
means that, for each truck trk in the domain, if the number 
of locations loc where at (trk, loc) is true is at most 
one in a state 5, then it is at most one in any successor state 
s' of s. If we prove that what is stated by the candidate is true 
and each truck is at a maximum of one location in the initial 
state, then each truck cannot be at multiple locations at the 
same time in any reachable state. Hence, for each truck, we 
can create a state variable that corresponds to the predicate 
at and represents the position of the truck. The values of 
this variable represent the presence of the truck in the vari- 
ous locations that it can occupy. 

In Helmert’s work, he considers only the cardinality set 
S = { 1 }. However, we consider the set S = { 0 , 1 } because, 
with durative actions, it is common for a proposition to be 
deleted at the beginning of an action (e.g. the location of an 
object being moved), and replaced by a new proposition at 
the end of the action (e.g. the new location of the object). 
This corresponds to a decrease in the weight of 7 to zero 
at the beginning of the action, and an increase back to one 
at the end. Allowing S = { 0 , 1 } could be useful in non- 
temporal domains as well, since it allows operators bringing 
the weight from zero to one to be classified as safe for invari- 
ance conditions. This approach therefore allows us to find 
more invariants than the techniques using only S = { 1 }. We 
will present relevant examples in the following section. Al- 
though we focus here on S = { 0 , 1 }, our technique for find- 
ing invariants can be generalized to larger cardinality sets. 

Invariance Conditions 

In order to show that a candidate C is an actual invariant, we 
need to guarantee that, for any instance 7 of C, the weight 
of 7 is within the cardinality set S = { 0 , 1 } in the initial 
state and all the operators in the domain V keep the weight 
within this set. When an operator satisfies this condition, we 
say that it is safe and so it does not threaten the candidate C. 

More formally, given an instance 7 of a candidate C , an 
operator op is safe if, for any situation where: i) the weight 
of 7 is less than or equal to one prior to executing op and 
ii) it is legal to execute op , the weight of 7 is guaranteed to 
remain less than or equal to one through the execution of op 
and immediately following op. A domain V is safe for C if 
and only if all operators in V are safe for any instance 7 of 
C. 

A sufficient condition for C to be an actual invariant is that 
the domain is safe for C. 

Given a candidate C and an instance 7, when can we en- 
sure that an operator op is safe, i.e. maintains the weight of 
7 within the cardinality set S = { 0 , 1 }? Clearly, if the op- 
erator does not change the weight of 7, then it is safe. On 
the other hand, if an operator increases the weight of 7 by 
two or more at any time-point, it is definitely not safe. If the 
operator increases the weight of 7 by one, there might be 
circumstances in which it is safe, depending on the structure 



of the conditions and the effects of the operator itself and on 
its interactions with other operators. 

Given an instance 7 of a candidate C, we consider safe an 
operator op if and only if it falls in one of the following six 
categories: 

1. Type N - Inert. The operator op does not affect the 
weight of 7. Clearly, an inert operator is safe because 
it preserves the weight of 7. Considering a simple 
Logistics domain, the figure below shows an example 
of such an operator with respect to the candidate C = 
({at (truck, loc) }, {truck}, {loc}). 

(at ?truck ?loc) 

(not (clean ?truck))) 


| w=k 



(clean ?truck)) 


2 . Type D: Decreasing. The operator op decreases the 
weight of 7 at some time-point, and does not increase it 
at any time point. A decreasing operator may or may not 
have a condition on 7, and the decrease may even be uni- 
versally quantified. Like an inert operator, a decreasing 
operator is safe because it does not cause an increase in 
the weight at any time-point, and therefore maintains the 
weight within the cardinality set S = { 0 , 1 }. The figure 
below shows one of several possible decreasing operators 
with respect to the candidate C = ({at (truck,loc)}, 
{truck}, {loc}). 

(at ?truck ?loc) 

1 w=1 

Type Dx | destroy-truck(?truck) | 

^ w=0 

(not (at ?truck ?loc)) 


3 . Type I: Increasing. The operator op increases the weight 
of 7 from zero to one. We identify three possible sub- 
cases: 


• Type Is and Ie: The operator op increases the weight 
of 7 by one at some time-point (start/end) and its con- 
ditions require that the weight of 7 be zero at the same 
time-point (start/end). Increasing operators of type Is 
and Ie are safe because they bring the weight from 
zero to one at just one time-point. The figure below 
shows an increasing operator at start and an increas- 
ing operator at end with respect to the candidate C = 
({at (truck, loc) }, {truck}, {loc}). 


forall (?loc) (not (at ?truck ?loc))) 
w=0 

Type Is 


I w=0 

s X 

| buih 

(at ?truck ?yard) 


build-truck(?truck ?yard) 


forall (?loc) (not (at ?truck ?loc))) 
w=0 


Type le ^ 

| build-truck(?truck ?yard) 


^ w=1 
(at ?truck ?yard) 


• Type lx: a condition at start guarantees that the weight 
of 7 is zero and an add effect at end increases the 


weight by one. The figure below shows an example 
of such an operator with respect to the candidate C = 

({at (truck, loc) }, {truck}, {loc}). 

forall (?loc) (not (at ?truck ?loc))) 

I w=0 

Type lx T . 

| build-truck(?truck ?yard) | 

A w=1 
(at ?truck ?yard) 


An operator of type lx is safe if it is mutex with all those 
operators that may increase the weight of 7 over its du- 
ration. The following picture shows a simple example 
of when this might happen. 


forall (?loc) (not (at ?truck ?loc))) 
1 w=0 

Type lx 


build-truck(?truck ?yard) 


(at ?truck ?loc1) 
^ w=1 


^ w=2 

(at ?truck ?yard) 


drive(?truck ?loc1 ?loc2) 


w=0 

(not ( at ?truck ?loc1 )) 


J— 

f w=1 


(at ?truck ?loc2) 


4 . Type B: Balanced. The operator op preserves the weight 
of 7 by checking that the weight is one at some time- 
point (start/end), decreasing the weight by one at that 
time-point and then bringing back the weight to one at 
that same time-point. Balanced operators are always safe 
because they act at only one time-point (start/end) and 
do not change the overall weight of 7. The figure below 
shows a balanced operator at start (Type Bs) and a bal- 
anced operator at end (Type Be) with respect to the can- 
didate C = ({at (truck, loc) }, {truck}, {loc}). 


(at ?truck ?loc1 ) 


Type Bs 


i 


W=1 

instant-drive(?truck ?loc1 ?loc2) | 


t 


w=0 (not ( at ?truck ?loc1 )) 

w=1 (at ?truck ?loc2) 


Type Be 


(at ?truck ?loc1 ) 


t 

instant-drive(?truck ?loc1 ?loc2) | 

t 


w=1 


w=0 (not ( at ?truck ?loc1)) 

w=1 (at ?truck ?loc2) 


5 . Type U: Temporarily Unbalanced. The operator op en- 
sures that the weight of 7 is one at start, brings the weight 
from one to zero at start or at end and then restores the 
weight to one at end. 

We have two different configurations for a temporarily un- 
balanced operator: 

• Type Us: a condition at start guarantees that the weight 
is one, a delete effect at start decreases the weight 
from one to zero, and an add effect at end restores 
the weight to one. The figure below shows an exam- 
ple of such an operator with respect to the candidate 
C = ({at (truck, loc) }, {truck}, {loc}). 


(at ?truck ?loc1) 


Type Us 


t w=1 

drive(? 


drive(?truck ?loc1 ?loc2) 


w=0 

(not ( at ?truck ?loc1)) 


T w=1 
(at ?truck ?loc2) 


An unbalanced operator of type Us is safe if it is mutex 
with all those operators that may increase the weight 
of 7 over its duration. The following picture shows a 
simple example of when this might happen. 

(at ?truck ?loc1 ) 

I w=1 

Type Us ? . 

| drive(?truck ?loc1 ?loc2) 1 

^ w=0 ^ w=2 

(not ( at ?truck ?loc1 )) (at ?truck ?loc2) 


forall (?loc) (not (at ?truck ?loc))) 
I w=0 

f 


build-truck(?truck ?yard) 


i w=1 
(at ?truck ?yard) 


Unbalanced operators of type Us are particularly com- 
mon because they model the usage of renewable re- 
sources. A renewable resource is needed during the ex- 
ecution of the action, so the weight goes from one to 
zero at start, but it is not consumed by the action, so the 
weight returns to one at end. 

• Type Ue: a condition at start guarantees that the weight 
is one and a delete and an add effect at end bring the 
weight from one to zero and then back to one. The fig- 
ure below shows an example of such an operator with 
respect to the candidate C = ({at (truck, loc) }, 
{truck}, {loc}). 


(at ?truck ?loc1) 
I w=1 

Type Ue 


drive(?truck ?loc1 ?loc2) 


(not ( at ?truck ?loc1)) w=0 
(at ?truck ?loc2) w=1 


An unbalanced operator of type Ue is safe if it is mu- 
tex with all operators that may alter the weight during 
its execution. Although this operator does not cause an 
overall change in the weight of 7 when executed in iso- 
lation, it might give rise to problematic situations when 
another operator opi capable of changing the weight is 
allowed to take place over its duration. This is because 
the application of opi may have the side effect of mak- 
ing the delete effect of op no longer applicable, which 
would in turn provoke an overall increase of the weight 
by two instead of one. The figure below exemplifies this 
situation. 


(at ?truck ?loc1) 
Type Ue 


ai nrucK noci 
I w=1 
Ue T 


drive(?truck ?loc1 ?loc2) 


(at ?truck ?loc1) 
I w=1 


(not ( at ?truck ?loc1)) 

(at ?truck ?loc2) w=2 


tow(?truck ?loc1 ?loc3) 


^ w=0 

(not ( at ?truck ?loc1 )) 


1 

(at ?truck ?loc3) 


One could argue that unbalanced operators of type Ue 
originate from a faulty description of renewable re- 
sources and so they should in reality be operators of 
type Us. We have found a few examples of operators 
of type Ue in the domains of previous IPCs, but none 
resulted in provable invariants. 

6. Type Q: Quantified Delete. The operator op sets the 
weight of 7 to zero at some time-point (start/end) through 
a universally quantified delete effect and then brings back 
the weight to one at the same time-point (start/end) or af- 
ter that. We distinguish three possible sub-cases: 

• Type Qs and Qe: a universally quantified effect sets 
the weight to zero at some time-point (start/end) and 
an add effect increases the weight by one at the same 
time-point (start/end). Operators of type Qs and Qe 
are safe because they ensure that only the single add 
effect will be true. The figure below shows an ex- 
ample of such operators with respect to the candi- 
date C = ({in (package, truck) }, {package}, 
{truck}). 

Type Qs unload-all-load-one(?package ?truck ) 

V SHE 

forall (?tr) (when (not (= ?tr ?truck))) w _g 
(not (in ?package ?truck))) 

(in ?package ?truck) w=1 


Type Qe 


unload-all-load-one(?package ?truck 


R- 


forall (?tr) (when (not (= ?tr ?truck))) 
(not (in ?package ?truck))) 

(in ?package ?truck) 


• Type Qx: a universally quantified effect at start sets 
the weight to zero and an add effect at end increases 
the weight by one. The figure below shows an ex- 
ample of such an operator with respect to the candi- 
date C = ({in (package, truck) }, {package}, 
{truck}). 

Type Qx unload-all-load-one(?package ?truck ) 

4 w=0 

forall (?tr) (when (not (= ?tr ?truck))) (in ?pa ckage ?truck) 

(not (in ?package ?truck))) 



An unbalanced operator of type Qx is safe if it is mutex 
with all those operators that may alter the weight during 
its execution. The following picture shows an example 
of when this might happen. 


Type Qx I unload-all-load-one(?package ?truck) I 


forall (?tr) (when (not (= ?tr ?truck))) 
(not (in ?package ?truck))) 


(at ?package ?loc) 


4 w=2 

(in ?package ?truck) 


I w=1 

| load(? 


load(?package ?truck ) 


^ w=0 
(not ( at ?package ?loc)) 


T w=1 
(in ?package ?truck) 


Inert and balanced safe operators represent the tempo- 
ral generalization of the non-threatening operators used in 
Helmert’s invariant synthesis (Helmert, 2009). The criteria 
for identifying increasing, decreasing and quantified delete 
operators can be readapted for use in non-temporal planning 


domains. They correspond to the use of the cardinality set 
S = { 0 , 1} instead of S = {1}, which allows us to capture 
a broader set of invariants than Helmert’s approach. In con- 
trast, unbalanced operators are specific to temporal planning 
and correspond to cases where the effects of an action are 
not fully realized until the end. Such operators can still be 
safe, as long as no other operator can disrupt the candidate 
during the execution of the operator. 

Temporal Mutex Conditions 

We now clarify the exact nature of the temporal mutex con- 
ditions that must hold in order to ensure the safeness of un- 
balanced operators and operators whose effects are split over 
time, such as operators of type Dx, lx, and Qx. 

In order to assess if an operator op is safe, we first need 
to establish what kinds of operators may disrupt the weight 
during the execution of op and then specify the exact mu- 
tex relationships that must hold between op and the possibly 
disrupting operators. 

Let us consider the second issue first. In general, how can 
we establish whether two durative PDDL operators are mu- 
tex or not? Since in PDDL2.2, effects can only happen at the 
start and end of the operators, and conditions can only be 
specified at the start, end, and over all, there are nine types 
of mutex. We refer the reader to (Smith and Jonsson, 2002) 
for a discussion of mutex between actions with general con- 
ditions and effects. 

Given two durative operators opi and op 2 , these nine 
types of mutex operators are the following: 

1 . Start- Start: opi and op 2 cannot start at the same time if: 
3p £ (Cond start (opl)UCond 0 n(opl)UEfF stor , t (opl)) : 
-ip S (Cond start (op2) U Cond a //(op2) U Eft sta rt(op2)) 

2. End-End : opi and op 2 cannot end at the same time if: 

3p £ (Cond en< j(opl) U Cond a ;;(opl) U ES end (opl)) : 
~ip S (Cond e „d(op2) U Cond a «(op2) U ES end (op2)) 

3. Start-End : opi cannot start at the time that op 2 ends if: 

3 p £ (Cond s(ar t (opi) UCond a M (opi) UEff s t ar( (opi)) : 
^p £ (Cond en< j(op2) U Eff erad (op2)) 

4. Invariant- Start: op 2 cannot start during opi if: 

3p G Cond a u(opl) : 

P e (Cond st art (op2) U Cond a /z(pp2) U Eff start (op2)) 

5. Invariant-End: op 2 cannot end during op\ if: 

3p G Cond a u(opl) : 

V € {Cond end (op2) U Cond a jz(qp2) U Eff end (op2)) 

6 . Invariant-Invariant: opi and op 2 cannot overlap if: 

3p G Cond a u(opl) : -i p G Cond a u(op2 ) 

In addition, we have: 7. mutex End-Start (dual to case 3), 
8 . mutex Start-Invariant (dual to case 4) and 9. mutex End- 
Invariant (dual to case 5). For brevity, we refer to such mu- 
texes as mutex-SS , mutex-EE , and so on. 

As for identifying possibly disrupting operators, we need 
to reason about the operators in the domain according to two 
criteria: i) what type of legal weight change they produce 
(from zero to one, from one to zero or from one to zero to 
one); and ii) at what time-points the changes happen. 


Following this reasoning, for each type of unbalanced op- 
erator op , we identify a set of mutex constraints that involve 
op and those operators that can possibly disrupt its weight. 
If these constraints are satisfied, then op is safe. 

• An increasing operator of type lx is safe if it is: 

1. mutex IS with any operator of type (I,Q)s 

2. mutex IE with any operator of type Us, (I,Q)x, and 

(I,Q)e 

• An unbalanced operator of type Us is safe if it is: 

1. mutex IS with any operator of type (I,Q)s 

2. mutex IE with any operator of type Us, (I,Q)x, (I,Q)e 

• An unbalanced operator of type Ue is safe if it is: 

1. mutex IS with any operator of type (I,Q,B)s 

2. mutex IE with any operator of type Us, (I,Q)x, and 
(I,Q,B,U)e 

• A quantified delete operator of type Qx is safe if it is: 

1. mutex IS with any operator of type (I,Q)s 

2. mutex IE with any operator of type Us, (I,Q)x, and 
(I,Q,U)e 

Decision Tree 

In Figure 1 , we show a binary decision tree T that can be 
used to determine whether an operator op is safe w.r.t an in- 
stance 7 of a candidate C or not. The internal nodes of the 
tree test the structure of the conditions and effects of the 
operator. The abbreviations stand for: Add-s — >> add effect 
at start, Del-s — » delete effect at start, W=0-s — >> weight is 
zero at start, UQ del-s — >■ universally quantified delete effect 
at start. Abbreviations for conditions and effects at end are 
analogous. On the basis of the configuration of the condi- 
tions and effects of the operator op , the leaf nodes assign a 
classification: either op is safe or it is unsafe (respectively, 
“OK” and “X” in the tree). The leaves of the tree marked 
with “OK” represent all the possible cases in which we ac- 
cept an operator as safe. Green labels in the figure link these 
cases with the five categories of safe operators described 
above. Close to the corresponding branches of the tree, we 
also give a graphical representation of the configuration of 
the operator’s conditions and effects. It is worth noting that a 
few of the operators in the tree are quite bizarre and unlikely 
to appear in practice. For example, operators of type 1 (such 
as Isle) could not even be executed without required concur- 
rency - some other operator would have to reduce the weight 
back to zero in the middle. Nevertheless, we have included 
these operators in the tree for completeness. 

Guess, Check and Repair Algorithm 

As with other related techniques (Gerevini and Schubert, 
2000; Helmert, 2009), our algorithm for finding invariants 
implements a guess, check and repair approach. We start 
from a simple set of initial candidates and use the decision 
tree in Figure 1 to evaluate if each candidate C is an invariant. 
If we reach a failure leaf for any operator op in the domain, 
before discarding C, we identify what features of op threaten 
C and exploit this knowledge for creating new candidates 



Add-s 


Types: 

N = Inert 
D = Decreasing 
I = Increasing 
B = Balanced 
U = Unbalanced 
Q = Quantified 



( (l,Q,B)sBe A 
del v y 
add ( 3 ) 


Figure 1: Decision Tree T for checking whether an operator op is safe w.r.t an instance 7 of a candidate C. 


that are guaranteed not to be threatened by the same opera- 
tor op. These new candidates need to be checked against the 
invariance conditions and might fail due to different threat- 
ening operators. The tree in Figure 1 associates, whenever 
possible, a set of fixes to dead leaves. 

When we create the set of initial candidates, we ig- 
nore constant predicates (Edelkamp and Helmert, 1999), i.e. 
predicates whose atoms have the same truth value in all the 
states (for example, type predicates). In fact, they are triv- 
ially invariants and so are typically not interesting. Among 
the modifiable atoms, we use initial predicates with the fol- 
lowing characteristics: the set <f> contains only one atom <j) 
and the set V contains only one counted variable. The can- 
didate Cat = ({ a t (truck, loc) }, {truck}, {loc}) is 
an example of an initial candidate. This choice comes from 
experience and is the same as for other related techniques 
(Helmert, 2009). 

Given an initial candidate, we test the safety of each oper- 
ator in the domain by traversing the decision tree in Figure 1 . 
The main difficulty associated with traversing the tree is that 
we can check the mutex constraints associated with some 


branches of the tree only when we know the type of each 
operator. The simplest way to handle this is to make two 
iterations: the first to classify operators according to types 
and the second to check the operators. However, we follow 
a more efficient approach by checking most of the operators 
during the first iteration, and just returning to do the mutex 
checks for those operators that require them, after all of the 
operators have been classified. We apply the following pro- 
cedure: 

1. Select a candidate invariant C and traverse the decision 
tree T for each operator in the domain V. 

2. If a node requiring a mutex check is reached for an op- 
erator op , save op in a bucket for that mutex check and 
proceed as if the mutex check succeeded. 

3. Run the corresponding mutex checks for the operators in 
the buckets. 

4. At any point in the process, if a failure leaf node is 
reached, discard the candidate C. 

5. At any point in the process, if a fix leaf node is reached, 


generate a new candidate for each possible fix, and start 
the process over. 

Step 2 in the above procedure classifies the operators ac- 
cording to the six types described in the previous section. 

Refining Candidates 

The choice of how to fix a failed candidate depends on 
the features of the operators that threaten it. More specif- 
ically, given a candidate C = (<F,F,V) that has been re- 
jected because it is threatened by an operator op , we refine 
C by picking a new atom 0, which is chosen on the basis of 
the structure of op as explained below, and adding it to the 
components’ set <f> of C. So, we obtain the new candidate 
C = ({<f> U </>}, F', V'), which will not fail for the same rea- 
sons as C, but might fail for different reasons. The new atom 
<p must involve only the variables in F and at most one other 
variable and must satisfy one of the following three criteria: 

1 . Fix SS: the atom </> unifies with a positive condition at 
start and a delete effect at start of op. 

2. Fix EE: the atom unifies with a positive condition at 
end (or over all) and a delete effect at end of op. 

3. Fix SE: the atom </> unifies with a positive condition at 
start and a delete effect at end of op. 

Given a candidate C and an instance 7, we apply fixes SS, 
EE and SE in the following cases: 

1. Fix SS when C is threatened by an operator op such that: 

• op has an add effect at start or at end increasing the 
weight of 7, but no delete effects or conditions involv- 
ing 7 either at start or at end (respectively, Leaf 8 and 
Leaf 22 in the decision tree in Figure 1); 

• op has the same configuration as safe operators of type 
lx or Qx, but it is actually unsafe because it does not 
satisfy the mutex conditions that ensure the weight re- 
mains within the cardinality set S = {0, 1} during its 
execution (respectively, Leaf 14 and Leaf 21). 

2. Fix EE when C is threatened by an operator op such that: 

• op is of type 14, 21 and 22 just described above; 

• op has the same configuration as safe operators of type 
Us, but it is actually unsafe because it does not satisfy 
the mutex conditions that ensure the weight remains 
within the cardinality set S = {0, 1} during its exe- 
cution (Leaf 16); 

3. Fix SE when C is threatened by an operator op of type 
14, 21 and 22 just described above. 

As an example, consider the Logistics domain with the 
operator unload-truck, shown in the figure below. 

(in ?package ?truck) 

w=1 

unload-truck(?package ?truck ?loc) 

^ w=0 J w=1 

(not (in ?package ?truck)) (at ?truck ?loc) 

For the candidate C at = ({at (package , loc) }, 
{package}, {loc}), we see that operator 


unload-truck threatens C a t because it increases 
the weight at end without decreasing it or checking that the 
weight is zero. If we traverse the tree in Figure 1 guided by 
the conditions and effects of the operator unload-truck, 
we reach leaf 22. Although this is a failure leaf, it indicates 
that, before discarding C at , we can try to apply fixes 
SS, EE and SE. Fix SS can be actually used in this case 
because the atom 0 =in ( ?package ?truck) appears 
both in the positive conditions at start and in the delete 
effects at start. Therefore, we add the candidate C at / in = 
({at (package, loc) , in (package, truck) }, 
{package}, {loc, truck}) to the list of candidates to 
check. By evaluating the new candidate C at j in against the 
invariance conditions, we will conclude that C at / in is in fact 
an invariant. 

If a candidate C is discarded because an operator op of 
type Us or Qx does not satisfy the mutex checks as re- 
quested, we have two additional options for fixing C. In par- 
ticular, if op is of type Us and is not mutex-IS with an op- 
erator opi of type Is or Qs, then we create new candidates 
by picking an atom (j) that must involve only the variables in 
F and at most one other variable and satisfy the following 
criteria: 

4. Fix M-SS: unifies with a positive condition at start and 

a delete effect at start of opi . In such a way, opi becomes 
of type Bs. 

If op is not mutex-IE with an operator opi of type (I,Q)e 
or (I,Q)x, then we create new candidates by: i) applying Fix 
M-SS so as to make opi of type Us and ii) picking an atom 
(f> that must involve only the variables in F and at most one 
other variable and satisfy the following criterium: 

5. Fix M-EE: the atom 0 unifies with a positive condition 
at end (or over all) and a delete effect at end of opi. In 
such a way opi becomes of type Be. 

Finally, if op is of type Qx and is not mutex-IS with an 
operator opi of type Is or Qs, then we create new candidates 
by applying Fix M-SS; if op is of type Qx and is not mutex- 
IE with an operator opi of type (I,Q)e or (I,Q)x, then we 
create new candidates by applying Fix M-EE. 

Experimental Results 

In this section, we present some experimental results for 
the invariant synthesis technique developed above. The cur- 
rent version of the algorithm is implemented in the Python 
language. The experiments were conducted by using a 2.53 
GHz Intel Core 2 Duo processor with a memory of 4 GB. 

Figure 2 presents the invariants that the algorithm finds 
for the temporal domains of the IPC-6 (2008). Each invariant 
is enclosed in braces where the predicate names indicate the 
components of the invariant, numbers not enclosed in square 
brackets indicate the positions of the fixed variables in the 
list of arguments of the corresponding predicate and num- 
bers enclosed in square brackets indicate the counted vari- 
ables. For example, {in 0 [1], at 0 [1]} indicates the invari- 
ant having {at (package, location) in (package, 
vehicle) } as components, package as a fixed variable, 
and { location, vehicle } as counted variables. Next 


Domains 

# INV SIS 

# Inv TIS 

# Fix TIS 

RT TIS 

Crew Planning-IPC-6 

0 

3 

0 

0.0054 

Elevators-Num-IPC-6 

0 

2 

1 

0.0025 

Elevators-Str-IPC-6 

0 

3 

1 

0.0037 

Modeltrain-Num-IPC-6 

3 

7 

1 

0.0089 

Openstacks-Adl-IPC-6 

2 

7 

4 

0.0043 

Openstacks-Num-IPC-6 

4 

10 

6 

0.0054 

Openstacks-Num-Adl-IPC-6 

2 

6 

4 

0.0030 

Openstacks-Str-IPC-6 

4 

11 

6 

0.0073 

Parcprinter-Str-IPC-6 

5 

7 

2 

0.0126 

Pegsol-Str-IPC-6 

0 

2 

1 

0.0008 

Sokoban-Str-IPC-6 

0 

3 

1 

0.0033 

Transport-Num-IPC-6 

0 

3 

1 

0.0030 

Woodworking-Num-IPC-6 

2 

7 

3 

0.0167 

Openstacks-IPC-5 

2 

7 

4 

0.0048 

Pathways-IPC-5 

0 

0 

0 

0.0003 

Pipesworld-IPC-5 

0 

8 

7 

0.0266 

Rovers-IPC-5 

4 

9 

0 

0.0142 

Storage-IPC-5 

0 

3 

2 

0.0071 

TPP-IPC-5 

0 

1 

0 

0.0006 

Trucks-IPC-5 

0 

2 

2 

0.0055 

Airport-IPC-4 

2 

2 

0 

0.0399 

Pipesworld-NT-IPC-4 

0 

4 

4 

0.0162 

Pipesworld-T-IPC-4 

0 

8 

7 

0.0270 

Satellite-IPC-4 

0 

2 

1 

0.0027 

UMTS -4 

0 

0 

0 

0.0079 

Depots-IPC-3 

0 

6 

5 

0.0113 

DriverLog-IPC-3 

0 

2 

2 

0.0051 

ZenoTravel-IPC-3 

0 

1 

1 

0.0031 

Rovers-IPC-3 

4 

9 

0 

0.0137 

Satellite-IPC-3 

0 

2 

1 

0.0027 


to each invariant, we report how many operators of each type 
we found during the synthesis of that invariant. The most 
common cases are: type 23, which means that the operator 
does not even potentially threaten the invariant because it is 
inert or decreasing, and type 15, which corresponds to the 
usage of a renewable resource. We also found a few opera- 
tors of type 6c, which correspond to balanced operators at 
start. If an invariant was obtained by applying a fix, then we 
report what type of fix was used. From Figure 2, we can 
conclude that the temporal domains of the IPC-6 are fairly 
well constructed. There are no instances of operators of type 
Ue, which would likely correspond to malformed renewable 
resources, and there are not many domains that include uni- 
versally quantified conditions or effects. 

In examining additional domains from previous IPCs, we 
have seen more variability in the types of operators. We 
found operators of types 6c, 11, 15, and 23. Additional oper- 
ators of types 8, 12, 16, 17, 18, and 22 were found while ex- 
amining candidate invariants that were ultimately rejected. 
Based on discussions with Will Cushing 2 , these findings ap- 
pear to be consistent with his analysis (Cushing et al., 2007). 

Table 1 compares the number of invariants (# Inv) found 
by the Temporal Invariant Synthesis (TIS) just discussed 
with those found by a Simple version of the Invariant Syn- 
thesis (SIS) for the temporal domains of the IPC-6, IPC- 
5, IPC-4 and IPC-3. The SIS represents a simple general- 
ization of Helmert’s invariant synthesis (Helmert, 2009) to 
the temporal case. In particular, it uses the cardinality set 
S = {1} instead of cardinality set S = {0, 1} and does not 
perform any mutex checks, which means that it considers 
safe only balanced operators of type Bs and Be. 

Table 1 also reports the number of invariants obtained by 
applying fixes (# Fix) and run time (RT) for generating in- 
variants for the temporal domains. The computational time 
is negligible; there is no significant delay associated with ei- 
ther checking a broad set of configurations in the operators’ 
conditions and effects or performing the mutex checks. 

Finally, Table 2 shows a comparison between the number 
of state variables obtained by instantiating invariants for do- 
mains of the IPC-6 coming from a Naive Invariant Synthesis 
(NIS), which basically produces a state variable with two 
truth values (true and false) for each atom in the domain, 
the Simple Invariant Synthesis (SIS) just described, and our 
Temporal Invariant Synthesis (TIS). In many domains the 
TIS produces a significant reduction in the number of state 
variables in comparison with the other two techniques. In six 
instances of Elevators- str, Sokoban-str, and Transport-Num 
the reduction is greater than an order of magnitude. 

Conclusions and Future Work 

In this paper, we presented a technique for automatically 
synthesizing invariants starting from temporal planning do- 
mains expressed in PDDL2.2. Our technique builds on 
Helmert’s invariant synthesis (Helmert, 2009), but extends 
it to apply to temporal domains and also identifies a broader 
set of invariants. This is achieved by considering the cardi- 
nality set S = {0, 1} instead of S = {1} and by analyzing 

2 Personal communication 


Table 1: Number of invariants (# INV), number of invariants com- 
ing from fixes (# Fix) and run time (RT) for generating invariants 
for the temporal domains of the IPC-6, IPC-5, IPC-4 and IPC-3 
by using the Temporal Invariant Synthesis (TIS) and the Simple 
Invariant Synthesis (SIS). 


the entire structure of an operator to assess its safety with 
respect to an invariant. Finding a wider set of invariants al- 
lows us to synthesize a smaller number of state variables to 
represent a domain. All the temporal planners that use state 
variables to represent the world greatly benefit from dealing 
with a relatively small number of state variables. 

Our technique can be incorporated in any translation 
from PDDL2.2 to a language based on multi-valued state 
variables. In particular, we have used the temporal in- 
variant synthesis described here in our translator from 
PDDL2.2 to NDDL, EUROPA2’s domain specification lan- 
guage (Bernardini and Smith, 2008). The use of this trans- 
lator, which includes the temporal invariant synthesis de- 
scribed here as one of its core steps, has facilitated the test- 
ing of EUROPA2 against domains of the IPCs originally ex- 
pressed in PDDL2.2. 

In the future, we intend to use information about types, 
which are available in PDDL2.2 domains, for identifying 
a more comprehensive set of invariants. As an exam- 
ple, consider a domain in which we have a predicate 
(pred ?argl - supertype ?arg2 - type) 
and the types subtype 1 and subtype 2 are both 
of type super type. Given an invariant candidate 



woodworking-numeric: 

{unused 0, wood 0 [1]} t-15: 2, t-23: 14 Fix SS 

{unused 0, treatment 0 [1]} t-15: 1 , t-23: 9 Fix SS 

{unused 0, surface-condition 0 [1]} 

t-15: 4, t-23: 12 Fix SS 

{unused [0]} t-23: 16 

{unused 0} t-23: 16 

{idle [0]} t-15: 9, t-23: 7 

{idle 0} t-15: 9, t-23: 7 

modeltrain-numeric: 

{next-train 1 [0], first-train-in-head-segment 0} 
t-6c: 2 , t-23: 384 Fix SS 
{switch-exit 0 [1]} t-15: 1, t-23: 385 
{switch-entrance 0 [1]} t-15: 1, t-23: 385 
{tail-segment 0 [1]} t-6c: 2 , t-23: 384 

{head-segment 0 [1]} t-6c: 2 , t-23: 384 
{idle [0]} t-15: 8, t-23: 378 
{idle 0} t-15: 8, t-23: 378 

openstacks-adl: 

{stacks-avail [0]} t-15: 2 , t-23: 43 
{waiting [0], started [Of shipped [0]} 
t-15: 2 , t-23: 43 Fix SS 
{waiting 0, started 0, shipped 0} 
t-15: 2 , t-23: 43 Fix SS 

{started [0], waiting [0]} t-15: 4, t-23: 44 Fix SS 
{started 0, waiting 0} t-15: 1 , t-23: 44 Fix SS 
{waiting [0]} t-23: 45 
{waiting 0} t-23: 45 

parcprinter-strips: 

{uninitialized } t-23: 41 
{timepoint 0 [1], location 0 [1]} 
t-15: 26, t-23: 15 Fix SS 
{notprintedwith 0 1 [2]} t-23: 41 
{notprintedwith 0 2 [1]} t-23: 41 
{notprintedwith 1 2 [0]} t-23: 41 
{notprintedwith 0 12} t-23: 41 
{hasimage 0 1 [2], notprintedwith 0 1 [2]} 
t-15: 4, t-23: 37 Fix SS 

sokoban-strips: 

{at 0 [1]} t-15: 3, t-23: 269 

{at 1 [0], clear 0} t-15: 3, t-23: 269 Fix SS 

{clear [0]} t-15: 3, t-23: 269 

crewplanning-strips: 

{unused [0]} t-15: 1, t-23: 22 
{unused 0} t-15: 1 , t-23: 22 
{currentday 0 [1]} t-15: 1, t-23: 22 

elevators-strips: 

{passengers 0 [1]} t-15: 2 , t-23: 478 
{lift-at 0 [1]} t-15: 4, t-23: 476 
{passenger-at 0 [1], boarded 0 [1]} 
t-15: 2 , t-23: 478 Fix SS 

pegsol-strips: 

{free 0, occupied 0} t-15: 1 , t-23: 31 Fix SS 
{occupied [0]} t-15: 1 , t-23: 31 

transport-numeric: 

{ready-loading [0]} t-15: 2 , t-23: 64 
{ready-loading 0} t-15: 2 , t-23: 64 
{in 0 [1], at 0 [1]} t-15: 3, t-23: 63 Fix SS 


Figure 2: Invariants for the temporal domains of the IPC-6. 


Domains 

#SV 

NIS 

SIS 

TIS 

Crew Planning - plO 

112 

112 

106 

Crew Planning - p20 

305 

305 

261 

Crew Planning - p30 

510 

510 

498 

Elevators-Num - plO 

193 

193 

21 

Elevators-Num - p20 

578 

578 

34 

Elevators-Num - p30 

1216 

1216 

49 

Elevators-Str - plO 

203 

203 

21 

Elevators-Str - p20 

592 

592 

34 

Elevators-Str - p30 

1240 

1240 

49 

Openstacks-Adl - plO 

97 

97 

57 

Openstacks-Adl - p20 

166 

166 

97 

Openstacks-Adl - p30 

235 

235 

137 

Openstacks-Num - plO 

71 

71 

29 

Openstacks-Num - p20 

121 

121 

49 

Openstacks-Num - p30 

171 

171 

69 

Openstacks-Num- Adi - plO 

85 

85 

57 

Openstacks-Num-Adl - p20 

145 

145 

97 

Openstacks-Num-Adl - p30 

205 

205 

137 

Openstacks-Str - plO 

83 

83 

29 

Openstacks-Str - p20 

142 

142 

49 

Openstacks-Str - p30 

201 

201 

69 


Domains 

#SV 

NIS 

SIS 

TIS 

Modeltrain-Num - plO 

397 

205 

191 

Modeltrain-Num - p20 

396 

204 

188 

Modeltrain-Num - p30 

910 

418 

390 

Parcprinter-Str - plO 

641 

641 

431 

Parcprinter-Str - p20 

1273 

1273 

673 

Parcprinter-Str - p30 

669 

669 

439 

Pegsol-Str - plO 

66 

66 

33 

Pegsol-Str - p20 

66 

66 

33 

Pegsol-Str - p30 

66 

66 

33 

Sokoban-Str - plO 

490 

490 

72 

Sokoban-Str - p20 

127 

127 

37 

Sokoban-Str - p30 

1131 

1131 

75 

Transport-Num - plO 

1292 

1292 

36 

Transport-Num - p20 

1292 

1292 

36 

Transport-Num - p30 

1772 

1772 

64 

Woodworking-Num - plO 

143 

143 

95 

Woodworking-Num - p20 

239 

239 

151 

Woodworking-Num - p30 

251 

251 

158 


Table 2: Number of state variables (# SY) for temporal domains of the IPC-6 that are obtained by instantiating invariants coming from: (1) 
a Naive Invariant Synthesis (NIS); (2) a Simple Invariant Synthesis (SIS); and (3) our Temporal Invariant Synthesis (TIS). 


C = ({pred (argl , arg2 ) }, {argl - supertype}, 
{arg2 - type}), suppose that no operator threatens C 
when argl is bound to an object of type subtype 1, but an 
operator op threatens C when argl is bound to an object of 
type subtype 2. In this case, our algorithm rejects the can- 
didate and, if no fix involving pred can be applied, the algo- 
rithm encodes pred with binary state variables. However, 
if we enrich the algorithm with the ability to use information 
about types, it will consider two more specific candidates 
C\ = ({pred (argl , arg2 ) }, {argl - subtypel}, 
{arg2 - type}) and C 2 = ({pred (argl , arg2 ) }, 
{argl - subtype2}, {arg2 - type}). Now, the 
algorithm will accept C\ as an invariant since it is not 
threatened by any operator, while it will fail C 2 since op 
threatens it. 
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